A datastore may be a repository for storing, managing, and distributing electronic data, and may store any of the data resources produced and/or utilized by an individual and/or an organization. Data resources may include any electronic data such as files, documents, media like music and video, records (e.g., electronic medical records), transaction data (e.g., financial transaction records), sensor data, and/or user profiles, and/or a portion of data thereof. The datastore may also include protected resources that are proprietary, confidential, and/or private data. A security system may require a user to be authenticated before the user can access the datastore and/or authorized before the user can utilize one or more of the protected resources (e.g., use the protected resource on a device and/or manage the protected resource on a server). An authentication process may be used by the security system to verify that the user is who they purport to be (e.g., validate an identity of the user and/or a device of the user). An authorization process may be used to determine whether the user is privileged to utilize the protected resource (e.g., watch a video file, access a corporate document, view personal information of a user profile).
The security system may require the user to provide one or more identity credentials at the time of an authentication process, each identity credential based on an authentication factor. There may be three common authentication factors: what the user “knows” (e.g., a password); what the user “has” (e.g., a device such as a fob); and what the user “is” (e.g., a biometric such as a fingerprint). In general, the greater the number of authentication factors used in the authentication process, the greater the certainty that the user is who they purport to be. For example, two-factor authentication employing both a password and a physical object may generally lead to greater security of the datastore than just a password.
However, use of a greater number of authentication factors may also decrease convenience in utilizing data resources of the datastore, and/or make using application programs that may utilize the datastore more confusing or even frustrating. This inconvenience, or “user friction,” may discourage the user from using the application program when it takes too long to log in or when the user cannot communicate one or more of the identity credential, for example due to a forgotten password. In an enterprise environment, user friction during the authentication process may also cause the user to try to operate outside enterprise security procedures. For example, the user might store protected resources on a local hard disk of the user's computer when enterprise policy requires the protected resources remain centrally administered.
Identity credentials such as passwords may also be easy to “social engineer” or hack. In a social engineering attack the user discloses the password to a seemingly well-intentioned person that is a hacker, for example by disclosing the password to an phony IT professional or typing it into a fake login screen of misleading website. Similarly, for convenience, users may choose passwords that are easy for hackers to crack or guess through the use of password libraries, or use the same password across multiple user profiles. Once obtained, the password may give the hacker access to the datastore for long periods without detection. Biometrics may provide additional certainty of the user's identity but may in some cases require expensive equipment. They may also be compromised, for example where a thumbprints of a person are stored in an electronic datastore and can be reproduced physically or digitally to fool the security system.
The user may be authenticated for a period of time or for a set amount of interaction with the datastore, for example to increase convenience to the user and/or to reduce computing overhead of the security system. In some cases, the user may be authenticated at the beginning of a session of interaction with the datastore. The user may be provided with a session token that the security system may check when the user requests one or more protected resources. However, the session token may remain relatively static and constantly transmitted over a primary channel of a network. A hacker may be able to fake the session token and/or relatively easily capture authentication credentials, allowing the hacker to covertly access the datastore, steal information, and/or destroy protected resources.
Once the user is authenticated, the security system may authorize a user when the user requests a given piece of data such as the protected resource from the datastore. For example, an access control list (ACL) may traditionally determine that the user is associated with the permission to access a particular file, and a computer may then copy and distribute the file to the user. However, it may be difficult to build systems that significantly distinguish the authentication process from the authorization process. For example, the security system may define security groups into which a set of data resources are placed and several users are associated (e.g., an admin group, a business development group). As a result, the user may be over-permissioned by having access to data resources that are unnecessary for the user's purpose, increasing risk to an organization that owns the datastore if that user acts against the organization's interest or loses his or her identity credentials. At the same time, the user may face an inconvenience (and/or the organization may suffer inefficiencies) when the user is under-permissioned, e.g., when requesting the protected resource from a different group for which the user is not generally permissioned.
As a result, current authentication processes may require a tradeoff between convenience (e.g., a fewer number of authentication factors) and stronger authentication (e.g., a greater number of authentication factors). Some identity credentials may be relatively easy to social engineer, may persist for longer than necessary due to system architecture, and/or may be difficult or expensive to implement (e.g., iris scanning). The authentication process and the authorization process may be relatively difficult to separate without increasing computing overhead and complexity, leading to protected resources that lack an appropriate scope of control within an organization. Therefore, the risk that the datastore will be subject to unauthorized access and protected data to unauthorized utilization, theft or damage may be increased. Once compromised, the datastore and/or the data of the datastore may lead to irreparable harm, for example when sensitive medical records, personal payment details or valuable trade secrets are stolen by hackers.